Is this patch has a problem? Or totally unacceptable?

I have tested it and found no problems using the BRAM option.

Hi gyurco,

Sorry for the delay, but please bear with me, I need to check it thoroughly before merging your patch.

No problem, just I was wondering if it's noticed.
In the patch, no signal timings should changed, the original behaviour of availability of the register value at the same time as the address changed is preserved by giving negative clock to the BRAM blocks. Still no timing issues on FPGAGen, where the master clock is 56MHz.

@ijor could you make a progress with the check?
As without enabling the BRAM option, it doesn't change any behavior, it should be perfectly safe. The ugliness of the negative clock for the BRAM is only effective when FX68K_ALTERA_REGS is defined, so in the default case, the performance is not affected at all.

@ijor could you make a progress with the check?
As without enabling the BRAM option, it doesn't change any behavior, it should be perfectly safe. The ugliness of the negative clock for the BRAM is only effective when FX68K_ALTERA_REGS is defined, so in the default case, the performance is not affected at all.

Sorry, not yet. I'm not concerned too much about the performance. As I told you over PM, even in the worst case, it might still be a reasonable compromise to trade speed for size in specific cases.

But there are a couple of other issues. One is that some enhancements I’m planning might require accessing multiple registers simultaneously. As you realize, that would not be possible if the registers are located in ram.

Oh, more than two registers at a time? It's for some kind of supporting save-states?